In the development and management of complex software systems, Object Oriented Programming (OOP) has become commonplace. OOP is a type of data programming in which programmers define not only the data type of a data structure, but also types of operation or methods that can be applied to the data structure. Through object modeling, a software system is described as a set of objects. Objects are programming abstractions that have identity, behavior, and state. Objects can have relationships or associations between one another. Also, objects can inherit characteristics, sometimes referred to as attributes from other objects. Object oriented programming requires an object-oriented programming language (OOPL). JAVA™, C++™ and SMALLTALK™ are three of the better known languages used. There are also object-oriented versions of PASCAL™.
A typical multi-tier client-server software system exhibits four predominant and distinct software layers. These are a presentation layer, a middleware layer, an application layer, and a persistence layer. Object orientation has been successfully applied primarily to the presentation and application layer of the above-mentioned software layers. There are “new component” based object modeling standards available such as (D) COM or CORBA that address object orientation in the middleware layer of a software system. In current sate-of-art technology however, the persistence layer of a software system is not addressed adequately in terms of object-orientation. Therefore, most applications still use relational database management systems (RDBMS) in the persistence layer of a complex software system.
A RDBMS models data using relational algebra. Relational modeling works in terms of truth predicates. A truth predicate defines what attributes are involved in the predicate and what the meaning of the predicate is. Other common terms of relational modeling include tuple, and relation value. A tuple is a set of attributes expressed most often as a single row in a table. The attributes make up the columns of the table, and the table itself is classed under a heading or relation. A relation value is the aggregation of the tuples under the relation or heading.
There are well-known tools in the art for mapping object models to relational models. This approach is known in the art as object-to-relational mapping. Object modeling, as described above, describes a system of objects that have identity, behavior, and encapsulated state. Relational models, quite differently from object models, describe a system by information. Therefore, a RDBMS has no distinct way of representing any of the primary properties of object modeling. For example, tuples, or rows, have neither identity nor encapsulation. Tuple attribute values are pure values so they have neither identity nor state. The disparity between the two approaches in programming causes what is known as an impedance-mismatch in the art. Programmers must write an extensive amount of code in order to successfully map objects to tables and data in tables to objects. Moreover, mapping objects to tables and vice versa, depending on the method used, can cause performance disadvantages in terms of user access to the relational data. For example, the number of database accesses required to perform a certain task, as well as the number of read and write operations associated with a task will depend in part on the efficiency of a mapping schema chosen for the system.
Because of the challenges described above, attempts have been made to address the persistence layer of a software system in terms of object orientation by providing object-oriented database management systems (OODBMS) instead of middleware solutions. Object oriented databases attempt to eliminate the need for object-to-relational modeling but they have not been accepted for business applications due to lack of standards and major limitations.
There are also object/relational database management systems (ORDBMS) available in current art that provide features from both relational and object environs. ORDBMS do have the ability to handle complex information and have object-oriented facilities and capabilities included. They combine the scalability, reliability, and concurrency of a modem RDBMS with the data modeling features of an object-oriented system. However, this technology is also new and not widely used. Moreover many of the more complex and critical software systems are legacy systems that are not economically replaceable, nor migratable.
The above-described approaches with reference to provision of OODBMS and ORDBMS are immature in available functionality and have not gained even a moderate acceptance in the market place. RDBMS are still the most widely used data management conventions in the persistence layer of complex software systems. In view of the scant acceptance of OODBMS and ORDBMS technologies, it has become apparent that better ways of object-to-relational mapping are desirable and, more particularly, a more developer-friendly method of performing database accesses in an object oriented way is needed.
Object relational mapping tools are known and used to facilitate complex object to relation mappings that attempt to minimize impedance mismatch and also try to address performance disadvantages. Some of these tools can also generate code for simple primary key-based accesses to RDBMSs in an object-oriented way. However, standard predicates for such accesses are pre-defined and must be strictly observed.
There are certain other tools which allow users to specify a query for database access in structured query language (SQL) and wrap the query into a function that is usable in existing application processing code. However, these tools do not provide object-oriented views of the RDBMS to user code. Moreover, they do not take advantage of any specific code patterns that can be specified by a user at an object-modeling level. The challenge in current art is to be able to provide an object-oriented way to access a RDBMS using any arbitrary predicate without having to code for the access.
Therefore, what is clearly needed is a query-abstraction and code-generation process that addresses the above issues by exploiting the information captured in object models and in SQL in order to enable user-friendly access to an RDBMS based on any arbitrary predicate or non-typical primary key based data access method.